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1.  INTRODUCTION 


This  report  presents  some  of  the  major  concepts  related  to  the  design 
of  a  testable  custom  large-scale  integrated  circuit  (CLSIC).  The  partitioning 
of  a  CLSIC  into  testable  circuit  structures,  the  basic  criteria  and  techniques 
used  in  testing,  and  the  addition  of  built-in  test  features  to  facilitate 
testing  are  discussed.  Built-in  test  features  for  CLSICs  include  the  built-in 
test  circuitry,  other  special  built-in  test  structures,  and  the  embedded  firm¬ 
ware  and  software  used  to  implement  built-in  testing.  For  example,  built-in 
test  features  may  include  on-chip  functional  circuit  structures,  such  as  signa¬ 
ture  generators,  comparators,  parity  trees,  counters,  encoders,  and  decoders; 
or  they  may  be  nonfunctional,  such  as  structures  used  for  process  monitoring 
or  to  enable  external  testing.  Nonfunctional  built-in  test  structures  are 
usually  process-peculiar  and  will  not  be  discussed  in  any  detail. 

A  testable  circuit  structure  refers  to  a  logical  organization  or 
architecture  of  a  CLSIC  subcircuit  consisting  of  the  functional  circuitry  to 
be  tested,  and  associated  built-in  test  circuitry.  The  circuitry  to  be  tested 
is  called  the  kernel.  Built-in  test  circuitry  consists  of  additional  cir¬ 
cuitry,  peripheral  to  the  functional  nature  of  the  CLSIC,  which  is  added  to 
the  chip  specifically  to  aid  in  testing  the  functional  circuitry.  .The  built- 
in  test  circuitry  may  be  functional  in  nature.  Examples  of  testable  circuit 
structures  are  level-sensitive  scan  designs  (LSSD),  built-in  logic  block 
observation  designs  (BILBO),  and  syndrome  testable  designs. 


2.  STRUCTURES  AND  DESIGN  STYLES 


Four  fundamental  units  of  logic  circuitry  are  used  to  implement  digital 
systems:  busses,  random  access  memories,  registers,  and  combinational  logic. 
These  fundamental  logic  units  are  referred  to  as  basic  circuit  structures. 

The  simplest  case  of  a  bus  is  a  wire,  of  a  random  access  memory  is  a  one-bit 
addressable  storage  element,  of  a  register  is  a  latch  or  flip-flop,  and  of  a 
combinational  logic  circuit  is  a  gate.  More  complicated  circuitry,  such  as 
decoders  and  multiplexers,  also  are  often  implemented  as  basic  structures. 

The  interconnection  of  two  or  more  of  these  basic  structures  (either  different 
or  identical  units)  results  in  a  circuit  structure.  The  difference  between  a 
basic  circuit  structure  and  a  circuit  structure  is  subtle.  Arithmetic  logic 
units,  counters,  and  shift  registers  are  Examples  of  simple  circuit  structures. 
Circuit  structures  often  have  architectural  styles  associated  with  them,  such 
as  pipeline,  bus-oriented,  or  bit-sliced. 

There  are  numerous  ways  of  implementing  a  basic  structure  in  a  single 
silicon  chip.  Circuit  design  considerations  differ  in:  (a)  how  transistors 
are  constructed,  (b)  how  transistors  are  interconnected  to  form  logic  func¬ 
tions,  (c)  how  logic  functions  are. interconnectei' ,  and  (d)  what  technology 
is  used.  Variations  in  circuit  design  and  logic  function  lead  to  different 
design  styles,  such  as  read  only  memories  (ROM),  programmable  logic  arrays 
(PLA),  and  gate  combinational  networks,  e.g.,  a  NAND  gate  network.  Hence,  the 
use  of  a  basic  structure  often  defines  a  circuit's  design  style.  For  example, 
a  combinational  logic  basic  structure  implementing  some  Boolean  function,  such 
as  an  arithmetic  logic  unit,  may  have  as  a  design  style  ROM,  PLA,  or  gate 
combinational  network. 

The  importance  of  identifying  design  styles  is  that  different  design 
styles  can  lead  to  unique  failure  mechanisms;  hence,  the  corresponding  basic 
structures  are  often  tested  differently.  This  is  not  necessarily  true  when 
exhaustive  testing  is  employed,  in  which  case  the  design  style  is  usually 
ignored. 


As  an  example,  consider  Che  PLA  design  sCyle.  Because  of  Che  high 
fan-in  ofCen  found  in  Che  AND  array,  PLAs  are  usually  noC  CesCed  very  cora- 
pleCely  by  random  CesC  vecCors.  Also,  PLAs  are  suscepCible  Co  unique  failure 
mechanisms,  such  as  exCra  or  missing  crosspoinC  connecCions.  Hence,  a  CesC 
mechodology  for  a  PLA  may  be  quice  differenC  from  ChaC  for  a  ROM  or  gaCe 
combinaCional  neCwork. 

OfCen,  circuic  sCrucCures  are  specially  designed  co  enhance  CesC- 
abiliCy,  such  as  in  Che  LSSD  mechodology.  ’  In  Chis  case,  a  combi¬ 
naCional  logic  basic  sCrucCure  C  and  a  shifc  regisCer  sCrucCure  S  are  inCer- 
connecCed  Co  enhance  Che  CesCing  of  C,  which  normally  has  Che  design  sCyle  of 
a  gaCe  combinaCional  neCwork.  The  archiCecCure  consisCing  of  Che  combinaCion 
of  Che  level-sensicive  scan  regisCer  connecCed  Co  C  is  said  co  consCiCuCe  Che 
LSSD  cesCable  sCructural  sCyle;  Che  combinaCional  logic  neCwork  C  which  is  Co 
be  CesCed  is  Che  kernel  of  Che  sCyle. 

In  general,  a  CLSIC  can  be  parcicioned  inCo  funcCional  blocks,  such  as 
conCrol ,  inpuc/ouCpuC ,  arichmecic  logic  unic ,  and  memory.  For  CesCing  pur¬ 
poses,  a  CLSIC  can  also  be  parcicioned  inCo  "CesCable"  subcircuics,  each  sub- 
circuic  being  CesCed  in  ics  own  unique  way.  These  subcircuics  may  correspond 
Co  funcCional  blocks.  By  definicion,  Chey  are  circuic  sCrucCures.  Ofcen,  one 
of  Che  firsC  sCeps  Co  be  Caken  in  Che  design  of  a  CesCable  CLSIC  is  Co  parCi- 
cion  ic  inCo  subcircuics.  The  subcircuics,  in  Curn,  define  circuic  sCrucCures 
whose  faulc  characCerisCics  are  well-defined  and  for  which  one  or  more  CesCing 
sCraCegies  are  known.  Each  such  sCrucCure  may  be  modified  by  Che  inclusion  of 
specified  builc-in  CesC  circuiCry  in  order  Co  enhance  iCs  CesCabilicy.  The 
subcircuics  so  defined  by  Che  parCicion  process  need  noC  be  disjoinc;  in  face, 
Chey  ofcen  have  builc-in  CesC  circuiCs  in  common. 


'Eichelberger ,  E.  B.  and  T.  W.  Williams,  "A  Logic  Design  SCrucCure  for  LSI 
TesCing,"  Proceedings  of  Che  14ch  Design  AuCoraaCion  Conference,  June  1977, 
pp.  462-468. 

2Eichelberger ,  E.  B.  and  T.  W.  Williams,  "A  Logic  Design  SCrucCure  for  LSI 
TesCabiliCy,11  J.  Design  AuComaCion  and  FaulC-ToleranC  CompuCing,  Vol.  2, 
May  1978,  pp.  165-178. 
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A  maximal  basic  circuit  structure  is  a  basic  structure  not  contained 
wichin  a  larger  basic  structure.  Often,  a  chip  is  tested  by  identifying  maxi- 
mal  basic  circuit  structures  and  testing  them  individually.  If  a  circuit 
structure  is  not  too  complex,  such  as  a  counter,  it  can  be  tested  as  an  entity 
For  complex  circuit  structures,  such  as  a  microprocessor,  testing  it  as  one 
entity  becomes  extremely  complex. 


3.  TESTING  TAXONOMY 


The  process  of  testing  a  circuit  structure  in  order  to  detect  or  locate 
hardware  faults  can  be  carried  out  in  one  of  two  modes,  known  as  external 
testing  and  self-testing.  The  former  deals  with  the  use  of  automatic  test 
equipment  to  test  the  circuit  structure;  the  latter  relies  on  the  chip  itself 
to  carry  out  the  testing  process.  A  circuit  structure  is  often  tested  using 
precomputed  test  programs  which  are  created  via  the  process  of  test  program 
generation.  Two  major  aspects  of  testing,  therefore,  are  test  program 
generation  and  design  for  testability. 

3.1  TEST  PROGRAM  GENERATION 


The  major  concepts  related  to  test  program  generation  are:  fault 
modeling,  test  generation,  response  evaluation,  fault  simulation,  and  fault 
location. 

3.1.1  Fault  Modeling 

Fault  modeling  deals  with  the  process  of  representing  the  actual  physi¬ 
cal  faults  in  the  circuit  (structure)  under  test  by  some  type  of  abstract 
model. 3,4  It  is  these  modeled  faults  which  are  actually  processed  by  most 
test  synthesis  and  analysis  tools.  Examples  of  commonly  used  fault  models  are 
listed  below: 

a.  Single  stuck-at  faults 

b.  Multiple  stuck-at  faults 

c.  Shorts  and  bridging  faults 


3Hayes,  J.  P.,  "Modeling  Faults  in  Digital  Logic  Circuits,"  Rational  Fault 
Analysis,  R.  Saeks  and  S.  R.  Liberty  (eds.),  Marcel  Dekker,  NY,  1977, 
pp.  78-95. 

'’Nickel,  V.  V.,  "VLSI  -  The  Inadequacy  of  the  Stuck  at  Fault  Model,"  Pro¬ 
ceedings  IEEE  International  Test  Conference,  November  1930,  pp.  373-331. 


d. 


Functional  faults 
Coupling  faults 
Pattern-sensitive  faults 


e . 

f . 

g.  Delay  faults 

h.  Parametric  faults 

i.  Nonclassical  MOS  faults,  such  as  opens 

3.1.2  Test  Generation 

Tests  for  a  circuit  can  be  determined  in  several  ways.5  The  most 
common  are  listed  below: 

a.  Manual 

b.  Algorithmic 

c.  Pseudorandom 

d.  Exhaustive 

e.  Standard  test  patterns 

The  method  used  to  generate  the  test  must  be  compatible  with  trte  level 
of  description  available  for  the  circuit  structure  under  consideration.  For 
example,  employing  a  path  sensitization  algorithm  may  require  a  gate  level 
description  of  a  circuit  structure;  employing  a  test  generation  algorithm  for 
PLAs  may  require  only  the  truth  table  of  the  functions  being  implemented; 
employing  a  functional/behavioral  approach  may.  require  a  high  level  language 
description  of  the  circuit  structure,  such  as  the  Instruction  Set  Processor 
(ISP)  notation. 


5Breuer,  M.  A.  and  A.  D.  Friedman,  Diagnosis  and  Reliable  Design  of  Digital 
Systems,  Computer  Science  Press,  Rockville,  Mi),  1976. 
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3-1.3  Response  Evaluation 


Once  tests  are  generated,  they  can  be  translated  into  a  test  program 
which  can  Chen  be  applied  either  by  the  automatic  test  equipment  or  by  built' 
in  test  features  to  the  circuit  under  test.  Based  upon  the  response  measured, 
the  circuit  under  test  can  be  characterized  as  being  faulty  or  not.  If  it  is 
faulty,  diagnosis  or  fault  location  can  be  carried  out.  Methods  for  process¬ 
ing  the  response  are  listed  below: 


Direct  comparison 

(1)  Stored  response 

(2)  Gold  unit  (standard  hardware) 

Comparison  with  data  compression  (compact  testing) 

(1)  Transition  counting6 7 * 9 

(2)  One's  counting  or  syndrome  testing7-9 

(3)  Signature  analysis10'11 


6Hayes,  J.  P. ,  "Testing  Logic  Circuit  by  Transition  Counting,"  Digest  of 
Papers  5th  International  Symposium  on  Fault-Tolerant  Computing,  June  1975, 
pp.  215-222. 

7Savir,  J. ,  "Syndrome-Testable  Design  of  Combinational  Circuits,"  Digest  of 
Papers  9th  International  Symposium  on  Fault-Tolerant  Computing,  June  1979, 
pp.  137-140. 

0Savir,  J.  "Syndrome-Testable  Design  of  Combinational  Circuits,"  IEEE 
Trans,  on  Computers,  Vol.  C-29,  June  1930,  pp.  442-451  (corrections: 

Nov.  1980). 

9Savir,  J.,  "Syndrome-Testing  of  ' Syndrome-Untestable '  Combinational 
Circuits,"  IEEE  Trans,  on  Computers,  Vol.  C-30,  August  1931,  pp.  606-608. 

10,,A  Designer's  Guide  to  Signature  Analysis,"  Hewlett-Packard  Aoplication 
Note  222,  Hewlett  Packard,  5301  Stevens  Creek  Blvd.,  Santa  Clara,  CA  95050, 
April  1977. 

^Nadig,  H.  J. ,  "Signature  Analysis-Concepts,  Examples  and  Guidelines," 
Hewlett-Packard  Journal,  May  1977,  pp.  13-21. 
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3.1.4  Fault  Simulation 


Normally,  the  fault  coverage  of  a  test  can  be  determined  by  using  a 
fault  simulator.5  Fault  simulation  can  be  carried  out  either  in  software  or 
in  hardware. 

3.1.5  Fault  Location 

Fault  location  can  be  carried  out  by  using  either  fault  dictionaries, 5 
diagnostic  routines,  or  effect-cause  analysis. 

3.2  DESIGN  FOR  TESTABILITY 


Design  for  testability  is  performed  for  several  reasons;  e.g.,  to 
reduce  the  complexity  of  test  generation  or  to  make  the  chip  partially  or 
fully  self-testable.  The  complexity  of  test  generation  may  be  reduced  by 
enhancing  controllability  and  observability.  The  chip  may  be  made  partially 
or  fully  self-testable  by  employing  built-in  test  structures  or  other  built-in 
test  features.  The  major  concepts  in  this  field  fall  into  ad  hoc  design 
methods,  structural  built-in  test  methods,  designing  with  easily  testable  com¬ 
ponents,  and  analysis  tools. 

3.2.1  Ad  Hoc  Design  Methods 


Numerous  ad  hoc  designs  for  testability  techniques  have  evolved  over 
the  years.  Most  have  dealt  with  small-scale  or  medium-scale  integrated 
circuits  on  printed  circuit  boards.  Included  in  these  techniques  are  concepts 
such  as  resettable  flip-flops,  test  points  to  increase  observability,  logical 
cutting  of  feedback  lines,  and  inhibiting  internal  clocks.  Extensions  to 


1  zAb ramov ic i ,  M.  and  M.  Breuer,  "Multiple  Fault  Diagnosis  in  Combinational 
Circuits  Based  on  an  Effect-Cause  Analysis,"  IEEE  Trans,  on  Computers, 
Vol.  C-29,  June  1980,  pp.  451-460. 
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these  early  techniques  have  led  to  many  of  the  huilt-in  test  methods  currently 
used  extensively  in  VLSI  circuits. 


Ad  hoc  design  methods  include: 

a.  Degating13 

b.  ‘Addition  of  test  points11**15 

c.  Bus  architecture1 

d.  Partitioning16 

17 

e.  Self-comparison 

f.  Self-oscillation17 


3.2.2  Structural  Built-in  Test  Methods 


Structural  built-in  test  methods  fall  into  two  major  categories,  namely, 
semi  built-in  and  fully  built-in  techniques.  Semi  built-in  test  methods  employ 
hardware  structures,  such  as  set/scan  registers,  to  increase  controllability 
and  observability.  Off-Line  test  generation  is  usually  still  required. 

Both  on-line  and  off-line  fully  built-in  test  techniques  exist.  The 
on-line  methods  are  examples  of  concurrent  testing.  The  off-line  methods, 
such  as  built-in  logic  block  observation,  are  gaining  in  popularity.  These 
methods  eliminate  the  need  for  off-line  test  generation  and  thus  minimize  the 
need  for  automatic  test  equipment.  These  techniques  often  require  minor  or  no 
changes  to  the  kernel  structure  being  tested. 


13Williams,  T.  W.  and  K.  P.  Parker,  "Design  for  Testability — A  Survey," 
Proceedings  IEEE,  Vol.  71,  January  1933,  pp.  93-112. 

^Hayes,  J.  P.  and  A.  D.  Friedman,  "Test  Point  Placement  to  Simplify  Fault 
Detection,"  Digest  of  Papers  10th  International  Symposium  on  Fault-Tolerant 
Computing,  June  1973,  pp.  73-73. 

15Hayes,  J.  P. ,  "On  Modifying  Logic  Networks  to  Improve  their  Diagnosabil- 
ity,"  IEEE  Trans,  on  Computers,  Vol.  C-23,  January  1974,  pp.  56—32. 

16Akers,  S.  B.  "Partitioning  for  Testability,"  J.  Design  Automation  and 
Fault-Tolerant  Computing,  Vol.  I,  February  1977,  pp.  133—146. 

17Buehler,  M.  G.  and  M.  W.  Sievers,  "Off-line,  Built-in  Test  Techniques  for 
VLSI  Circuits,"  Computer,  June  1932,  pp.  69-32. 
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Some  popular  structural  built-in  test  methods  include: 


a.  Semi  built-in 

(1)  Level-sensitive  scan  design1*2 

(2)  Scan  path18 

(3)  Random-access  scan19 

(4)  Scan/set  logic20 

(5)  Partitioning21 

b.  Fully  built-in 

(1)  On-Line 

2  2 

o  Error  detection  and  correction  codes 
o  Totally  self-checking  circuits23 

o  Self-verification21* 

(2)  Off-Line 

o  BILBO25.26 

o  Store  and  generate27 


18Funatsu,  S.,  N.  Wakatsuki,  and  T.  Arima,  "Test  Generation  Systems  in 
Japan,"  Proceedings  of  the  12th  Design  Automation  Conference,  June  1975, 
pp.  114-122.- 

19Ando,  H. ,  "Testing  VLSI  with  Random  Access  Scan,"  Digest  of  Papers  COMPCON 
30,  February  1980,  pp.  50-52. 

20Stewart,  J.  H. ,  "Future  Testing  of  Large  LSI  Circuit  Cards,"  Digest  of 
Papers  IEEE  Semiconductor  Test  Symposium,  October  1977,  pp.  5-17. 

21McCluskey,  E.  J.  and  S.  Bozorgui-Nesbat ,  "Design  for  Autonomous  Test," 

IEEE  Trans,  on  Computers,  Vol.  C-30,  November  1931,  pp.  366-875. 

22Peterson,  W.  W.  and  E.  J.  Weldon,  Error-Correcting  Codes,  2nd  Edition, 

MIT  Press,  Cambridge,  MA,  1972. 

23Wakerly,  J. ,  Error  Detecting  Codes,  Self-checking  Circuits  and  Applica¬ 
tions,  American-Elsevier ,  NY,  1978. 

2l*Sedmak,  R.  M. ,  "Design  for  Self-Verification:  An  Approach  for  Dealing 
with  Testability  Problems  in  VLSI-Based  Designs,"  Proceedings  IEEE  Test 
Conference,  1979,  pp.  112-120. 

25Konemann,  B.,  J.  Mucha  and  G.  Zwiehoff,  "Built-in  Logic  Block  Observa¬ 
tional  Techniques,"  Digest  of  Papers  1979  Test  Conference,  October  1979, 
PP*  37-41. 

“Mucha,  J.,  "Hardware  Techniques  for  Testing  VLSI  Circuits  3ased  on 
Built-in  Tests,"  Digest  of  Papers  COMPCON  31,  February  1931,  pp.  366-369. 

27Agarwal,  V.  K.  and  E.  Ceruy,  "Store  and  Generate  Built-in  Testing 

Approach,"  Digest  of  Papers  llth  International  Symposium  on  Fault-Tolerant 
Computing,  June  1981,  pp.  35-40. 
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o  Verification  of  Walsh  coefficients28 

o  Autonomous  testing29*30 
o  Syndrome  testing8’9 

3.2.3  Designing  with  Easily  Testable  Components 

Designing  with  easily  testable  components  is  a  methodology  which  deals 
primarily  with  the  design  of  the  kernel  itself,  and  where  the  main  objective 
is  to  make  the  kernel  easy  to  test.  A  simple  example  would  be  those  techniques 
which  rely  heavily  on  the  use  of  exclusive-or  gates.  For  such  circuits,  a 
single  error  on  an  input  always  produces  an  output  error,  making  the  concept 
of  path  sensitization  particularly  easy  to  achieve. 


This  methodology  includes: 

a.  EOR  trees31 

•  •  •  3  2 

b.  Canonic  Reed-Muller  circuits 

c.  Easily  testable  PLAs33 

d.  Easily  testable  iterative  logic  arrays3 '* 

e.  Bit-slice  systems35 


28Susskind,  A.  K. ,  “Testing  by  Verifying  Walsh  Coefficients,"  Digest  of 

Papers  11th  International  Symposium  on  Fault-Tolerant  Computing,  June  1931, 

pp.  206-208. 

McCluskey,  E.  J.  and  S.  Bozorgui-Nesbat ,  "Design  for  Autonomous  Test," 
Proceedings  IEEE  International  Test  Conference,  November  1930,  op.  15-21. 
30Bozorgui-Nesbat ,  S.  and. E.  J.  McCluskey,  "Structured  Design  for  Testa¬ 
bility  to  Eliminate  Test  Pattern  Generation,"  Digest  of  Papers  19-th  Inter¬ 
national  Symposium  on  Fault-Tolerant  Computing,  June  1980,  pp.  153-163. 

3  Seth,  S.  C.  and  K.  L.  Kodandapani,  "Diagnosis  of  Faults  in  Linear  Tree 
Networks,"  IEEE  Trans,  on  Computers,  Vol.  C-26,  January  1977,  pp.  29-33. 
32Saluja,  K.  K.  and  R.M.  Reddy,  "Fault  Detecting  Test  Sets  for  Reed-Muller 
Canonic  Networks,"  IEEE  Trans,  on  Computers,  Vol.  C-24,  October  1975, 
pp.  995-998. 

33Fujiwara,  H.  and  K.  Kinoshita,  "A  Design  of  Programmable  Logic  Arravs  with 
Universal  Tests,"  IEEE  Trans,  on  Computers,  Vol.  C-30,  November  1981, 
pp.  823-823. 

3<*Friedman,  A.  D.  ,  "Easily  Testable  Iterative  Systems,"  IEEE  Trans,  on 
Computers ,  Vol.  C-22,  December  1973,  pp.  1061-106'+. 

35Sridhar,  T.  and  J.  P.  Hayes,  "A  Functional  Approach  to  Testing  Bit-Slice  1 
Microprocessors,"  IEEE  Trans,  on  Computers,  Vol.  C-30,  August  1931, 
pp.  563-571. 
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3.2.4  Analysis  Tools 

Several  analysis  tools  have  been  proposed  for  aiding  design  for 
testability.  These  analysis  tools  usually  estimate  the  degree  of  control¬ 
lability  and  observability  of  the  various  signal  lines  in  a  circuit.  Based  on 
these  results,  the  circuit  design  should  be  modified,  if  necessary,  in  order 
to  enhance  testability. 

Several  analysis  tools  are: 

a.  Measurements 

(1)  COMET36 

(2)  SCOAP37*38 

(3)  TMEAS39 

(4)  CAME LOT 90 

4  1 

b.  Design:  Automatic  design  for  testability 


3.3  STRUCTURE  AND  TESTING 


Four  important  factors  to  be  considered  in  testing  a  kernel  are: 


a.  Fault  modes 

b.  Whether  or  not  a  single  vector  or  a  sequence  of  vectors  are 
required  to  detect  a  fault 


36Chang,  H.  Y.  and  S.  W.  Heimbigner,  "LAMP:  Controllability,  Observability 
and  Maintenance  Engineering  Technique  (COMET),"  Bell  System  Tech.  J., 

Vol.  53,  October  1974,  pp.  1505-1534. 

37Goldstein,  L.  H.  and  E.  L.  Thigpen,  "SCOAP:  Sandia  Controllability 

Observability  Analysis  Program,"  Proceedings  of  the  17th  Design  Automation 
Conference,  June  1980,  pp.  190-196. 

38Goldstein,  L.  H.,  "Controllability/Observability  Analysis  of  Digital 
Circuits,"  IEEE  Trans.  Circuits  and  Systems,  Vol.  CAS-26,  September  1979, 
pp.  685-693. 

39Grason,  J.,  "TMEAS,  A  Testability  Measurement  Program,"  Proceedings  of  the 
16th  Design  Automation  Conference,  June  1979,  pp.  156-161. 

"Bennetts,  R.  G. ,  et  al.,  "CAMELOT:  A  Computer-Aided  Measure  for  Logical 

Testability,"  IEE  Proceedings,  Vol.  128,  Part  E  (Comp.  &  Digital  Techniques), 
London,  September  1981,  pp.  177-139. 

"Chen,  T-H.  and  M.  A.  Breuer,  "Automatic  Design  for  Testability  via  Test¬ 
ability  Measures,"  IEEE  Transactions  on  Computer-Aided  Design,  Vol.  CAD-4, 
January  1985,  pp.  3-11. 
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c.  Complexity  of  test  generation 

d.  Timing 

These  factors  are  primarily  influenced  by  the  structure  of  a  kernel  and  its 
design  style. 

Fault  modes  are  often  a  function  of  design  style.  RAMs  exhibit  the 
phenomenon  of  adjacent  pattern  interference;  PLAs  are  susceptible  to  cross- 
point  failures  (extra  or  missing  connections);  and  gate  combinational  networks 
are  often  tested  for  stuck-at  faults,  shorts,  and  sometimes  memory  retention. 

For  a  combinational  circuit,  only  one  vector  is  usually  required  to 
detect  a  fault,  while  for  sequential  circuits  a  sequence  of  test  vectors  is 
often  necessary.  Faults  in  combinational  circuits  which  induce  memory  reten¬ 
tion  may  require  a  sequence  of  two  vectors  to  detect. 

The  complexity  of  test  generation  is  strongly  related  to  design  style 
as  well  as  circuit  structure.  For  RAMs,  standard  test  sequences  usually 
exist.  Automatic  test  generation  is  usually  a  difficult  if  not  impossible 
task  for  complex  random  sequential  circuits.  For  PLAs,  special  algorithms 
exist  which  make  test  generation  a  fairly  effective  and  efficient  process. 

Finally,  timing  issues  related  to  factors  such  as  races,  hazards,  and 
static  and  dynamic  logic  are  a  function  of  both  design  style  and  circuit 
structure.  For  example,  asynchronous  circuits  are  circuit  structures  and  are 
susceptible  to  races.  A  RAM  design  style  may  be  susceptible  to  pattern  inter¬ 
ference  faults  which  are  both  timing-  and  data-sensitive. 

In  summary,  different  design  styles  and  circuit  structures  have  unique 
testing  characteristics  and  are  thus  amenable  to  unique  testing  approaches  and 
built-in  test  strategies.  As  an  example,  a  PLA.  can  be  built  sucn  that  the 
signal  values  on  the  row  (product)  and  column  (word)  lines  have  odd 
parity;33  this  concept  is  not  directly  applicable  to  a  gate  combinational 
network  implementation  of  the  same  functions.  A  unique  logic  structure  for 
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Che  testing  of  internal  arrays,  and  the  testing  for  pattern-sensitive  faults 
in  RAMs  are  discussed  in  the  literature.42’1*3 


1,2Eichelberger,  E.  B. ,  et  al.  ,  "A  Logic  Design  Structure  for  Testing  Internal 
Arrays,"  Proceedings  of  the  3rd  USA-Japan  Computer  Conference,  October  1973, 
pp.  266-272. 

v3Hayes,  J.  P.,  "Detection  of  Pattern  Sensitive  Faults 'in  Random  Access 

Memories,"  IEEE  Trans,  on  Computers,  Vol.  C-24,  February  1973,  pp.  150-157. 


-  22 


4. 


EEST  STRATEGIES 


A  test  strategy  for  a  kernel  structure  is  the  complete  process  involved 
in  testing  the  structure.  This  includes  the  following  three  main  attributes: 

a.  Off-line  test  generation 

b.  Run-time  test  hardware 

Automatic  test  equipment  (external) 

Built-in  test  (internal) 

c.  Test  accessibility 

Controllability 

Observability 


4.1  OFF-LINE  TEST  GENERATION 

Off-line  test  generation  is  the  method  used  to  derive  test  vectors  and 
sequences.  This  process  is  necessary  for  some  types  of  test  strategies,  e.g. , 
in  the  LSSD  methodology,  but  not  for  others,  e.g.,  when  a  circuit  is  tested 
using  the  BILBO  methodology.  There  are  several  ways  to  carry  out  off-line 
test  generation,  some  of  which  are  summarized  below: 

a.  Manual 

Circuit-oriented,  e.g.,  process-sensitized  paths 
Functional,  e.g.,  execute  every  instruction 

b.  Algorithmic/heuristic 

PODEM**  ** 

D-algorithm1* 5 


','*Goel,  P.,  "An  Implicit  Enumeration  Algorithm  to  Generate  Tests  for  Combi¬ 
national  Logic  Circuits,"  Digest  of  Papers  10th  International  Symposium  on 
Fault-Tolerant  Computing,  October  1980,  pp.  145-150. 
l,SRoth,  J.  P.  ,  "Diagnosis  of  Automata  Failures:  A  Calculus  and  a  Method," 
IBM  J.  Research  and  Development,  Vol.  10,  July  196o,'  pp.  273-291. 
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PLA  test  generation** 6 

*47 

Delay  test  generation 

LASAR  (D-LASAR,  LASAR  5. 6)** 8 

•  4  9 

Functional 

c.  Pseudo-random50*51 

d.  Exhaustive  (not  normally  done  off-line) 

e.  Standard  test  sets 

GALPAT  for  RAMs5*52 

Universal  test  sets  for  PLAs33’53 

Except  for  exhaustive  and  standard  test  sets,  tests  once  generated  are 
usually  processed  through  a  fault  simulator  to  determine  fault  coverage. 

Note  that  the  process  of  off-line  test  generation  can  involve  the 
overhead  of  a  complex  and  sophisticated  suite  of  software  modules,  including 
design  capture,  testability  analysis,  test  generation,  and  fault  simulation 
routines.  The  resulting  tests  are  often  processed  via  additional  software 


**6Eichelberger ,  E.  B.  and  E.  Lindbioom,  "A  Heuristic  Test-Pattern  Generator 
for  Programmable  Logic  Array,'*  IBM  J.  Research  and  Development,  Vol.  24, 
January  1980,  pp.  15-22. 

**7Lesser,  J.  D.  and  J.  J.  Shedletsky,  "An  Experimental  Delay  Test  Generator 
for  LSI  Logic,"  IEEE  Trans,  on  Computers,  Vol.  29,  March  1980,  pp.  235-248. 

**8Thomas,  J.  J.,  "Automated  Diagnostic  Test  Programs  for  Digital  Networks," 
Computer  Design,  Vol.  10,  August  1971,  pp.  63-67. 

**9Thatte,  S.  M.  and  J.  A.  Abraham,  "Test  Generation  for  Microprocessors," 

IEEE  Trans,  on  Computers,  Vol.  C-29,  June  1980,  pp.  429-441. 

50Sastin,  0.,  et  al. ,  "Probabilistic  Test  Generation  Methods,"  Digest  of 
Papers  3rd  International  Symposium  on  Fault-Tolerant  Computing,  June  1973, 
p.  171. 

51Parker,  K.  P.  ,  "Adaptive  Random  Test  Generation,"  J.  Design  Automation  and 
Fault  Tolerant  Computing,  Vol.  I,  October  1976,  pp.-  62-83. 

52ilnatek,  E.  R.  ,  A  User's  Handbook  of  Semiconductor  Memories,  'Jiley- 
Interscience ,  NT,  1977. 

53Hong,  S.  J.  and  D.  L.  Ostapko,  "FIIPLA:  A  Programmable  Logic  Array  for 
Functional  Independent  Testing,"  Digest  of  Papers  10th  Internet iona  1 
Symposium  on  Fault-Tolerant  Computing,  October  1980,  pp.  131-136. 
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to  create  a  fault  dictionary,  if  required,  and  via  a  translator  in  order  to 
obtain  a  test  program  that  runs  on  a  specified  piece  of  automatic  test 
equipment . 


4.2  RUN-TIME  TEST  HARDWARE 


Run-time  test  hardware  is  the  hardware  used  during  the  actual  testing 
process  of  the  structure.  This  hardware  is  used  to  produce  the  test  vectors 
required  to  test  the  circuit  structure  as  well  as  process  the  responses  ob¬ 
tained.  Table  1  summarizes  some  of  the  hardware  used  in  this  process.  Two 
main  categories  of  hardware  are  used:  external  automatic  test  equipment  and 
internal  built-in  test  circuitry. 


Table  1.  Run-Time  Test  Hardware 


o  Off-chip  automatic  test  equipment 
o  On-chip  built-in  test  circuitry 
Generation  of  test  stimuli 
BILBO  register 

Linear  feedback  shift  register 
Counter  (exhaustive  testing) 

ROM  (stored  test  patterns) 

General  sequential  circuit 
Gray  code  generator 

Processing  of  test  responses 

Signature  generator 
BILBO  register 

Syndrome  generator/one's  counter 

Transition  counter 

Comparator 

RAM  (store  responses) 

Parity  detector 

Single  error  correction-double  error 
detect  ion 

General  sequential  circuit 


4.3 


TEST  ACCESSIBILITY 


During  the  testing  process,  one  needs  a  hardware  mechanism  in  order  to 
actually  apply  the  test  vectors  to  the  inputs  of  the  kernel  structure  under 
test,  as  well  as  observe  the  response  data  produced  at  the  outputs  of  tnis 
structure.  Since  this  structure  is  often  deeply  buried  within  a  chip,  built-in 
test  features  are  often  added  to  the  circuit  to  implement  these  controllability 
and  observability  functions.  Table  2  indicates  some  examples  of  how  that  ac¬ 
cessibility  is  achieved. 


Table  2.  Test  Accessibility 


o  Input 

Primary  inputs 
Scan-in  registers 
LSSD  registers 
BILBO  register 
Multiplexers 

o  Output 

Primary  outputs/test  points 
Scan-out  registers 
LSSD  registers 
BILBO  registers 
Multiplexers 


In  some  cases,  such  as  with  a  BILBO  register,  the  run-time  test  hard¬ 
ware  and  the  test  accessibility  registers  are  one  and  the  same.  For  the  LSSD 
methodology,  this  is  not  the  case.  Tests  are  first  generated  off-line,  usually 
using  some  type  of  test  algorithm;  external  hardware  (automatic  test  equipment) 
is  then  used  at  test  run  time  to  generate  and  process  the  tests.  LSSD  regis¬ 
ters  are  then  used  only  to  achieve  input  and  output  access  to  the  structure 
under  test. 
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In  summary,  a  test  strategy  involves  three  key  concepts;  namely,  a 
means  for  generating  input  test  data,  the  hardware  required  to  produce  the 
test  vectors  and  process  responses  during  the  testing  cycle,  and  a  means  for 
applying  the  input  test  data  to  the  input  lines  and  observing  the  response 
data  at  the  output  lines  of  the  circuit  structure  under  test.  In  some  cases 
the  kernel  itself  is  modified  in  order  to  enhance  its  testability. 33 


5.  TEST  STRATEGY  MEASURES 


Numerous  test  strategies  exist.  With  each  test  strategy  one  can  asso¬ 
ciate  everal  measures  dealing  with  performance  criteria,  constraints,  and 
goal;  An  example  of  a  performance  criterion  is  the  length  of  time  it  takes 
to  test  a  circuit  structure;  an  example  of  a  constraint  is  that  the  input  and 
output  pin  requirements  for  the  built-in  test  circuitry  be  less  than  some  given 
quantity;  finally,  an  example  of  a  goal  is  that  the  test  strategy  achieve  at 
least  98  percent  fault  coverage  of  the  single  detectable  stuck-at  faults. 

The  three  concepts  of  performance,  constraints,  and  goals  have  been 
lumped  together  because  they  are  usually  highly  interrelated,  and  often 
tradeoffs  are  made  between  them.  For  example,  achieved  fault  coverage  is 
often  a  function  of  the  expense  one  is  willing  to  incur  in  test  generation. 

The  incremental  increase  in  fault  coverage  as  a  function  of  cost  may  be 
extremely  high  as  one  approaches  100  percent  coverage.  Also,  for  sequential 
circuits,  the  incremental  increase  in  test  length  for  each  1  percent  addi¬ 
tional  fault  coverage  may  become  extremely  large.  Hence,  all  goals  may  not  be 
feasible.  Unfortunately,  the  quantitative  prediction  of  performance  measures 
is  a  difficult  task.  One  cannot,  for  example,  predict  a  priori  the  cost  of 
test  generation  versus  fault  coverage  for  a  given  circuit. 

Because  of  these  dichotomies,  the  concepts  of  performance,  constraints, 
and  goals  have  been  combined  into  the  general  category  of  measures.  In 
Table  3,  several  important  measures  are  listed  which  mav  need  to  be  considered 
in  selecting  a  test  strategy  for  a  circuit  structure. 

The  tradeoff  between  more  area  for  built-in  test  circuitry  and  decreased 
chip  functionality  leads  to  a  classic  battle  between  chip  designers  and  users. 
Hence,  the  driving  force  for  using  built-in  test  circuitry  comes  from  design 
specifications  where  the  testability  and  functionality  of  the  chip  are  made 
equally  important  design  criteria. 
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Table  3.  Measures  Associated  with  a  Test  Strategy 


Ml 

Yield  and  area 

effect  due  to  built-in  test  circuitry 

Example:  o 

LSSD  often  requires  a  5  to  20  percent  area 
overhead 

M2 

Test  Application  Time 

Example:  o 

In  LSSD,  each  test  vector  is  shifted  sequentially, 
slowing  down  the  test  process 

M3 

Input  and  output  pin  demand 

Example:  o 

LSSD  requires  four  additional  pins 

M4 

Fault  coverage 

and  fault  types 

Examples:  o 

For  LSSD,  coverage  of  the  single  stuck-at  fault  can 
be  arbitrarily  high  and  can  be  measured  via  fault 
simulation 

o 

For  BILBO  testing,  coverage  is  difficult  to 
determine 

*  o 

For  autonomous  testing,  coverage  is  essentially 
complete  for  all  fault  modes 

M5 

Test  input  or 

output  storage  volume  (on  chips) 

Examples:  o 

For  microdiagnostics ,  test  volume  is  high. 

o 

For  signature  generation,  volume  is  low. 

o 

For  LSSD,  no  on-chip  storage  is  required. 

M6 

Performance  degradation 

M7 

Preprocessing 

(off-line)  costs 

M3 

Cost  of  off-line  automatic  test  equipment 

M9 

Cost  of  accommodating  engineering  changes 
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lest  application  time  is  usually  critical  when  expensive  automatic  test 
equipment  is  employed.  When  a  chip  is  part  o£  a  large  system,  sucn  as  a  space 
satellite  which  employs  off-line  self-test  procedures,  testing  time  may  be  im¬ 
portant  because  it  may  significantly  affect  the  time  the  system  is  not  avail¬ 
able  for  normal  use. 

Performance  degradation  deals  with  the  effect  on  a  circuit's  operating 
characteristics  during  its  functional  operation  due  to  built-in  test  hardware. 
For  example,  using  a  pair  of  level-sensitive  latches  in  a  feedback  oath  (as 
found  in  LSSD)  instead  of  some  other  form  of  flip-flop  may  reduce  the  system 
clock  rate  by  a  small  amount. 

Preprocessing  cost  deals  with  the  process  of  off-line  test  generation 
and  the  associated  costs  of  acquiring  and  executing  the  required  software. 

Finally,  the  cost  of  processing  engineering  changes  varies  widely  for 
different  test  strategies.  When  off-line  test  generation  is  employed,  pro¬ 
cessing  an  engineering  change  can  be  quite  costly. 
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6.  TESTABLE  DESIGN  METHODOLOGY 


The  combination  of  a  kernel  structure  S  and  a  test  strategy  (test 
generation,  run-time  test  hardware,  and  hardware  for  accessibility)  consti¬ 
tutes  a  testable  design  methodology.  If  the  structure  S  has  a  design  style  D, 
then  it  can  be  said  that  the  testable  design  methodology  is  for  design  style  D. 

The  general  form  for  a  testable  design  methodology  is  represented  as 
follows : 


Al.  A  kernel  structure  to  be  tested 

(optional:  A  basic  circuit  structure  and  its 
design  style) 

A2.  A  test  strategy 

A2.1  An  off-line  test  generation  strategy 
A2.2  A  run-time  testing  environment 
A2.3  Hardware  for  test  accessibility 


6.1  EXAMPLE:  LEVEL-SENSITIVE  SCAN  DESIGN  (LSSD) 


As  an  example,  an  LSSD  is  associated  with  a  testable  design  methodologv 
having  the  following  attributes: 


Al  Gate  combinational  network 

A2.1  Test  generation  algorithm/fault 

s imula tor/ translator 
A2.2  Automatic  test  equipment 
A2.3  Level-sensitive  scan  design  registers 


Figure  1  indicates  the  major  components  associated  with  the  LSSD  test¬ 
able  design  methodology.  In  Figure  2  a  specific  example  of  a  testable  circuit 
structure  having  an  LSSD  testable  structural  style  is  shown. 


33 


A  BASIC  STRUCTURE  S  (combinational 


HAVING  AN  ISSD/TSS 


Fig.  2.  Testable  Structure  with  a  Level-Sensitive 
Scan  Design  Testable  Structural  S't’yle 
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The  space  of  testable  design  methodologies  can  be  thougnt  of  as  a  multi¬ 
dimensional  space  having  the  following  three  main  components: 

a.  The  structure  of  the  circuit  to  be  tested  and  possibly  its 
basic  structure  and  design  style 

b.  The  test  strategy  selected  to  test  the  circuit 

c.  The  value  of  the  measures,  such  as  Ml  through  M9,  associated 
with  the  above  two  items 

Given  this  space,  some  testable  design  methodologies  can  be  judged  to 
be  good,  others  to  be  poor.  For  example,  replacing  the  gate  combination  net¬ 
work  by  a  RAM  in  the  LSSD  methodology  would  not  lead  to  a  useful  testable 
design  methodology. 

6.2  DESIGN  PROBLEM 

The  main  tasks  in  designing  a  testable  CLSIC  chip  can  be  stated  as 
follows : 

a.  Partition  a  design  into  circuit  structures.  Depending  on  the 
testing  strategy  to  be  used,  some  or  all  of  these  structures 
may  be  basic  circuit  structures  having  well-defined  design 
styles. 

b.  Select  an  appropriate  test  strategy  for  each  structure. 

c.  Modify  the  design  as  necessary  to  implement  the  selected 
testable  design  methodologies  which  satisfy  all  measures 
associated  with  the  chip. 


7.  CHIP  BUILT-IN  TEST  CIRCUITRY 


In  making  a  chip  testable,  several  standard  hardware  structures  are 
often  added  to  the  chip  in  order  to  enhance  its  testability.  Examples  of  such 
built-in  test  circuits  are: 

a.  Set/scan  registers,  e.g.,  LSSD  registers 

b.  Counters  (generates  2n  test  vectors) 

c.  BILBO  registers 

d.  Comparators 

e.  Linear  feedback  shift  registers 

f.  Parity  generators 

Over  the  last  several  years,  increased  levels  of  observability  and 
controllability  in  VLSI  circuits  have  been  obtained  by  replacing  normal  flip- 
flops  in  a  circuit  by  dual  mode  registers  which,  in  normal  mode,  act  as  normal 
flip-flops.  In  the  test  mode,  they  act  as  shift  registers,  enabling  test  vec¬ 
tors  to  be  scanned  into  the  circuit  and  test  responses  to  be  scanned  out.  To 
achieve  exhaustive  testing,  counters  can  be  added  to  a  circuit  so  that  all 
possible  test  patterns  can  be  generated.  To  carry  out  ones  or  transition 
count  testing,  a  count  register  can  be  used.  Between  these  two  extremes,  one 
can  employ  linear  feedback  shift  registers,  such  as  in  the  BILBO  methodology, 
to  either  generate  pseudorandom  test  vectors  or  to  generate  a  signature. 
Finally,  a  comparator  can  be  used  to  compare  a  generated  signature  with  a 
stored  correct  signature.  When  these  test  circuits  and  others  are  used, 
powerful  testable  structural  styles  can  be  created. 

Except  for  the  parity  generator,  the  test  circuits  listed  previously 
are  used  for  off-line  testing.  When  on-line  testing  is  used,  then  other 
built-in  test  circuits  are  employed.  They  are  usually  used  to  implement  some 
coding  or  decoding  scheme.  Other  examples  of  such  test  circuits  are  self¬ 
checking  checkers. 5 
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3.  EXAMPLES  OF  TESTABLE  DESIGN  METHODOLOGIES 


This  section  briefly  illustrates  a  few  popular  testable  design 
methodologies . 

8.1  LEVEL-SENSITIVE  SCAN  DESIGN1’2 


Probably  the  most  well-known  testable  design  methodology  is  the  LSSD 
testable  design  methodology  introduced  by  IBM.  This  methodology  has  been 
depicted  in  Figures  1  and  2. 

8.2  SCAN  PATH  DESIGN18 

This  methodology  is  similar  to  the  LSSD  testable  design  methodology. 

The  main  differences  lie  in  the  type  of  flip-flops  used  in  the  registers  and 
the  clocking  scheme  employed. 

8.3  SCAN-SET  DESIGN20 

The  scan-set  testable  structural  style  is  shown  in  Figure  3.  Note  that 
the  kernel  structure  is  now  a  sequential  circuit;  hence,  the  off-line  test 
generation  process  for  this  methodology  can  be  significantly  more  complex  than 
that  for  the  previous  two  methodologies.  The  register  can  either  load  data 
(observability)  in  parallel  from  test  points  in  the  kernel  structure  and  shift 
these  data  out  (scan-out),  or  else  scan-in  new  data  (controllability)  and  apply 
these  data  to  test  points  in  the  kernel. 

8.4  RANDOM  ACCESS  SCAN  DESIGN  19 

The  testable  structural  style  for  the  random  access  scan  testabLe  design 
methodology  is  snown  in  Figure  4.  Again,  off-line  test  generation  is  required 
along  with  automatic  test  equipment,  and  the  kernel  is  combinational.  For  this 
testable  structural  style,  the  flip-flops  in  the  original  sequential  circuits 


39 


SCAN-SET 


Fig.  3.  Testable  Structural  Style  Used  in  the 
Scan-Set  Testable  Design  Methodologv 
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X-SCAN  ADDRESS 


Fig.  4.  Random  Access  Scan  Testable  Structural  Style 
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are  made  individually  addressable  during  Che  testing  mode,  and  their  contents 
are  set  and  read  via  the  automatic  test  equipment.  During  the  normal  mode  of 
operation,  the  kernel  and  flip-flops  in  the  addressable  storage  array  operate 
as  a  normal  sequential  circuit. 

8.5  BUILT-IN  LOGIC  BLOCK  OBSERVATION  DESIGN2 5,26 

This  testable  structural  style  is  an  example  of  a  fully  built-in  test 
approach;  hence,  no  off-line  test  generation  is  used,  and  only  minimal  auto¬ 
matic  test  equipment  is  required.  The  BILBO  registers  carry  out  four  functions 
for  testing:  controllability,  test  vector  generation,  observability,  and  test 
response  processing  (signature  generation). 

Figure  5  shows  the  testable  structural  style  used  in  the  BILBO  testable 
design  methodology.  The  kernel  is  again  combinational  logic  and  usually  of  the 
gate  combination  network  design  style.  Since  this  approach  is  based  upon 
pseudorandom  test  patterns,  a  ROM  or  PLA  design  style  is  not  suitable.  The 
circuit  is  tested  by  configuring  the  BILBO  register  on  the  left  as  a 
pseudorandom  pattern  generator  and  the  BILBO  on  the  right  as  a  signature 
generator. 

8.6  SYNDROME  DESIGN7 ’ 8 1 9 

The  testable  structural  style  for  the  syndrome  testable  design  method¬ 
ology  is  shown  in  Figure  6.  Again,  the  kernel  is  combinational,  but  this 
approach  is  applicable  to  gate  combinational  network,  PLA,  or  ROM  design 
styles.  Only  a  single  output  is  indicated.  Testing  is  accomplished  by  having 
the  counter  produce  all  2n  input  vectors,  while  the  count  register  counts  the 
number  of  l's  on  the  output.  The  correct  number  of  l's  is  the  number  of  min- 
terms  in  the  function  realized  by  C  and  is  denoted  by  K.  Then  S  =  K/211  is 
said  to  be  the  syndrome.  Fault  detection  is  achieved  by  comparing  the  final 
state  of  the  count  register  with  S.  In  this  built-in  self-test  methodology, 
no  off-line  test  generation  is  required,  and  the  automatic  test  equipment 
requirements  are  minimal.  Often,  the  design  of  the  circuit  C  (for  gate  combi¬ 
national  network  and  PLA  design  styles)  is  modified  to  enhance  testability; 


Fig.  6.  Syndrome  Testable  Structural  Style 


e.g.,  a  syndrome  testable  circuit  is  one  for  which  every  single  stuck-at  fault 
is  detectable  by  this  testing  approach. 


There  are  several  variations  to  this  form  of  testing.  For  autonomous 
testing, 21* 29> 30  the  output  of  the  kernel  is  directly  observed  by  an  automatic 
test  equipment,  rather  than  compacted  into  a  signature  (syndrome).  This  form 
of  testing  thus  guarantees  detection  of  all  faults  which  are  not  sequential  in 
nature.  Alternatively,  the  response  can  be  processed  via  a  linear  feedback 
shift  register,  and  again  a  signature  can  be  generated. 

8.7  EASILY  TESTABLE  BIT-SLICED  DESIGN35 

While  bit-sliced  architectures  are  usually  implemented  via  intercon¬ 
necting  chips,  as  the  level  of  integration  increases  these  architectural 
styles  will  be  used  more  extensively  at  the  chip  level.  One  reason  for  this 
is  regularity  in  layout  and  testing.  A  testable  structural  style  ideal  for 
bit-sliced  architectures  has  been  developed.  One  version  of  this  architecture 
is  for  Cl-testable  arrays.  To  introduce  this  concept,  a  few  definitions  are 
needed.  An  iterative  logic  array  is  a  one-dimensional  cascade  of  identical 
cells  (see  Fig.  7).  The  cells  can  be  either  combinational  or  sequential 
circuits.  An  iterative  logic  array  is  said  to  be  C-testable  if  it  can  be 
tested  with  a  constant  number  of  test  patterns,  independent  of  the  array  size 
N.  Let  T  be  a  test  set  that  tests  an  iterative  logic  array  D  completely  under 
the  assumption  that  only  one  cell  in  the  array  is  faulty.  Then  D  is  I-testabl 
with  respect  to  T  if  the  expected  responses  to  T  appearing  at  the  vertical 
outputs  of  every  cell  L^  of  D  are  identical.  A  Cl-testable  iterative  logic 
array  is  both  C-testable  and  I-testable  with  respect  to  some  test  set  T.  The 
necessary  and  sufficient  conditions  for  an  iterative  logic  array  to  be 
Cl-testable  have  been  determined.3** 

In  Figure  7,  L^,  L2>....Ljj  represents  the  Cl-testable  iterative 
logic  array  to  be  tested.  The  normal  inputs  and  outputs  3re  shown.  The  test 
T  can  be  stored  off-chip  and  applied  via  automatic  test  equipment  or  on-chip 
and  stored  in  a  ROM.  The  equality  checker  determines  if  the  responses  from 
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Fig.  7.  Bic-Sliced  Tascable  ScrucCural  Sryle 
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each  L.  are  identical. 

1 

snown,  but  the  concept 
output  lines. 

Off-line  test  generation  is  required  for  this  methodology;  for  complex 
cells,  this  process  may  be  quite  difficult  and  require  the  use  of  checking 
sequences. Sl*  Real-time  test- hardware  can  be  either  on-line  or  off-line. 

Test  application  to  the  kernel  is  achieved  via  the  multiplexers,  while  observ 
ability  of  the  responses  is  not  required  due  to  the  equality  checker  and  the 
concept  of  I-testability . 

8.8  SUMMARY 


The  case  of  a  single  output  line  from  each  is 
can  be  easily  generalized  to  the  case  of  multiple 


In  summary,  fully  built-in  testing  deals  with  those  test  strategies 
where  the  role  of  the  external  test  equipment  is  minimal.  BILBO  and  syndrome 
testing  are  examples  of  methodologies  which  employ  fully  built-in  testable 
structural  styles.  The  general  architecture  for  such  a  style  is  shown  in 
Figure  8.  Table  4  summarizes  the  various  options  for  each  block  in  Figure  3. 
When  built-in  test  structures  are  added  to  a  circuit,  care  must  be  taken  to 
ensure  that  the  test  structures  are  themselves  tested,  either  implicitly  or 
explicitly.  Also,  when  several  different  testable  structures  exist  on  a  chip 
some  additional  hardware  overhead  may  be  required  to  control  the  test  process 


5,*Friedman,  A.  D.  ,  and  P.  Menon,  Fault  Detection  in  Digital  Circuits, 
Prentice  Hall,  NJ,  1971. 
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Fig.  8.  General  Form  for  a  Fully  3uilt-in 
Testable  Structural  Style 
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Table  4.  Some  Options  in  the  Design  of  a  Fully 
Built-in  Testable  Structural  Style 


o  Stimulus  Generator 

o  Hardware  test  generation 

o  random  patterns  using  a  linear  feedback  shift  register 
o  all  input  combinations  using  a  linear  feedback  shift  register 
or  a  counter  (exhaustive) 

o  some  specified  patterns  using  a  nonlinear  feedback  shift 
register 

o  Stored  test  patterns 

o  Store  and  generate — store  some  pre-calculated 
patterns  as  initial  values  for  a  linear  feedback 
shift  register 

o  Functional  circuit 

o  Sequential  circuit — can  be  partitioned  into  combinational 
parts  using  set/scan  registers 

o  Combinational  circuit — partition  into  manageable  subcircuits 
o  Response  analyzer 

o  Use  compressed  responses 
o  syndrome  (one's  counting) 

o  signature  using  linear  feedback  shift  register 
o  transition  counting 

o  Store  the  correct  responses 
o  Generate  the  correct  response 

o  Compare  responses  with  correct  ones  and  generate 
go  or  no-go  signal 

o  Controller 

o  Control  transition  between  test  mode  and  normal 
mode 

o  Control  testing  process 


9.  TESTABLE  DESIGN  METHODOLOGIES  FOR  PROGRAMMABLE  LOGIC  ARRAYS 


Numerous  techniques  for  testing  the  PLA  design  style  have  been  sug¬ 
gested.  Figure  9  indicates  several  testable  design  methodologies  for  PLAs 
according  to  certain  attributes,  such  as  whether  or  not  they  support  con¬ 
current  testing,  produce  a  self-testing  PLA,  require  off-line  test  generation, 
and  are  based  upon  a  special  design  approach.  Naturally,  these  techniques 
could  have  been  classified  and  grouped  differently,  such  as  by  fault  coverage 
area  overhead. 

Figures  10  through  12  indicate  the  testable  structural  styles  corres¬ 
ponding  to  just  three  of  the  techniques  listed  in  Figure  9. 

9.1  PROGRAMMABLE  LOGIC  ARRAY  WITH  UNIVERSAL  TEST  SET 


Figure  10  indicates  a  testable  structural  style  for  a  PLA  which  employs 

a  universal  test  set,  hence  no  test  pattern  generation  is  required. 33  The 

normal  design  of  the  PLA  is  shown  in  heavy  lines..  The  medium  lines  indicate 

added  built-in  test  structures,  and  the  thin  lines  indicate  wires.  The  product 

terra  selector  is  a  shift  register;  the  data  in  this  register  enable  and  disable 

the  product  lines  in  the  array.  The  AND  array  is  extended  by  one  product  line 

such  that  each  input  row  has  an  odd  parity;  a  word  parity  line  is  also  added 

to  the  OR  array.  The  inputs  y^,  y^,  are  used  to  control  the  circuit 

during  the  normal  and  test  modes.  An  error  is  indicated  by  testing  the  two 

lines  (Z,  ,  Z„).  This  test  can  be  done  on-chip  or  off-chip.  The  D.  is 
12  in 

a  new  input  used  to  supply  data  to  the  product  term  selector  register.  Nor¬ 
mally,  the  universal  test  set  is  stored  off-chip  and  is  applied  via  the  auto¬ 
matic  test  equipment. 

If  the  PLA  has  n  inputs  and  m  prod.uct  lines,  then  tne  number  of  tests 
in  the  universal  test  set  is  2n  +  3m.  These  tests  detect  all  single  stuck-at 
faults  in  the  decoder  blocks  f  and  the  PLA,  all  crosspoint  faults  in  the  PLA, 
and  all  stuck-at  faults  in  the  parity  chain  £1.  • 
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9.2 


AUTONOMOUSLY  rESTA3LS  PROGRAMMABLE  LOGIC  ARRAYS 


Figure  11  indicates  what  is  referred  to  as  an  autonomously  testable 
structural  PLA  style.61  This  form  of  testing  is  very  similar  to  the  univer¬ 
sal  test  set  approach,  except  that  rather  than  store  the  universal  test  set 
and  have  them  applied  via  an  automatic  test  equipment,  the  autonomous  test 
approach  generates  the  test  patterns  on-chip. 

For  this  design,  a  product  term  selector  register,  several  additional 
parity  word  and  product  term  lines,  and  the  parity  chains  have  again  been  re¬ 
placed  by  parity  trees  to  enhance  their  testability. 

The  control  for  normal  and  test  modes  may  still  be  external;  however, 
the  input  test  data  and  the  data'for  D^  are  now  all  generated  on-chip  by 
the  feedback  value  generator  which  is  a  simple  sequential  circuit.  At  the  end 
of  the  test  process,  the  product  term  selector  register  contains  a  signature; 
it  is  decoded  by  the  flag  circuit  which  produces  an  error  flag  if  a  fault  has 
been  detected. 

This  approach  employs  n  +  2m  +  8  tests  and  detects  all  cross-point 
faults  in  the  PLA  as  well  as  all  single  stuck-at  faults  in  the  entire  circuit , 
except  for  parts  of  the  feedback  value  generator  and  flag  circuit.  These  can 
be  duplicated  if  necessary. 

9.3  PROGRAMMABLE  LOGIC  ARRAYS  WITH  CONCURRENT  ERROR 

DETECTION  AND  TESTING 

Figure  12  indicates  a  PLA  testable  structural  style  which  supports  con¬ 
current  error  detection.57  The  PLA  must  be  designed  so  that  it  has  concur¬ 
rent  product  lines,  i.e.,  exactly  one  product  term  is  true  for  every  input 
vector.  This  condition  usually  increases  the  size  of  the  PLA.  Since  the  PLA 
inputs  exist  as  a  two-rail  circuit  (x^,  x'. ),  a  totally  self-checking  two-rail 
checker  is  used  to  detect  stuck-at  faults  on  input  lines.  A  parity  out¬ 
put  word  is  added  to  the  OR  array,  and  a  parity  tree  is  used  to  detect 
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errors  on  Che  outputs.  Since  concurrent  testing  is  employed,  a  totally  self¬ 
checking  1  out  of  m  checker  can  be  used  to  detect  errors  on  Che  product 
1 ine  s . 

During  normal  operation,  this  testable  structural  style  will  detect  any 
of  the  following  faults  which  produce  output  errors:  single  stuck-at  faults, 
shorts  between  adjacent  lines,  and  crosspoint  faults.  Most  transient  faults 
are  also  detected.  Since  it  is  possible  that  the  normal  inputs  may  not  com¬ 
pletely  test  and  ,  it  may  be  necessary  to  carry  out  off-line  cesting 
so  that  these  circuits  can  be  completely  tested. 


10.  SUMMARY 


This  report  has  presented  a  survey  of  some  of  the  important  concepts 
related  to  the  design  of  a  testable  CLSIC.  Both  testing  and  design  for  test¬ 
ability  have  been  discussed.  Several  design  for  testability  concepts  have  bee 
presented,  with  emphasis  on  structures  for  serai  and  fully  built-in  testing. 

In  addition,  an  approach  to  achieve  testable  designs  has  been  suggested 
In  this  approach,  it  is  necessary  to  first  partition  a  CLSIC  into  structures 
to  be  tested  as  separate  entities.  Some  of  these  structures  may  be  basic 
structures  and  have  design  styles.  Often  the  characteristics  inherent  in  a 
structure  or  its  design  style  dictate  a  testing  approach.  The  concept  of  a 
test  strategy,  consisting  of  off-line  test  generation,  run-time  test  hardware, 
and  built-in  test  structures  for  input  and  output  accessibility,  was  intro¬ 
duced.  Given  a  selected  test  strategy  for  a  structure  to  be  tested,  a  test¬ 
able  structural  style  is  created.  A  testable  chip  thus  consists  of  instances 
of  testable  structures,  each  of  which  corresponds  to  some  testable  structural 
style.  The  result  of  using  these  concepts  in  an  orderly  and  effective  way, 
satisfying  the  goals  and  constraints  imposed  by  the  design  specifications, 
constitutes  a  testable  design  methodology. 
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